perm filename LISP.BUG[BUG,LSP]8 blob
sn#659290 filedate 1982-05-14 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00042 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00007 00002 BUG-LISP and LISP-FORUM
C00012 00003 ∂03-Apr-81 0610 JerryB at MIT-AI (Gerald R. Barber) Improving the LISP working environment by taking a lesson from...
C00030 00004 ∂18-Jun-81 2147 Richard M. Stallman <RMS at MIT-AI> nested function definitions interfering with extensibility.
C00048 00005 ∂28-Sep-81 0617 Mark L. Miller <MILLER at MIT-AI> Suggested new lambda-list syntax
C00049 00006 ∂11-Jan-82 0932 George J. Carrette <GJC at MIT-MC> backquote trivia, for you history fans.
C00051 00007 ∂11-Jan-82 0939 HES@MIT-AI
C00058 00008 ∂11-Jan-82 1551 Don Morrison <Morrison at UTAH-20> clarification regarding backquote query
C00061 00009 ∂12-Jan-82 1446 Jon L White <JONL at MIT-MC> 'backquote' actions
C00073 00010 ∂16-Jan-82 1132 William G. Dubuque <WGD at MIT-MC>
C00092 00011 ∂25-Jan-82 2316 FININ at WHARTON-10 (Tim Finin) Interlisp and MacLisp (almost)
C00109 00012 ∂30-Jan-82 0728 kwh@MIT-AI minilisp
C00113 00013 ∂30-Jan-82 1405 Jon L White <JONL at MIT-MC> Comparison of "lambda-macros" and my "Two little suggestions ..."
C00121 00014 ∂30-Jan-82 1446 Jon L White <JONL at MIT-MC> The format ((MACRO . f) ...)
C00123 00015 ∂01-Feb-82 0752 Jon L White <JONL at MIT-MC> Incredible co-incidence about the format ((MACRO . f) ...)
C00125 00016 ∂01-Feb-82 0847 HIC at SCRC-TENEX Incredible co-incidence about the format ((MACRO . f) ...)
C00129 00017 ∂17-Feb-82 2001 Jon L White <JONL at MIT-MC> SHARPM
C00142 00018 ∂22-Feb-82 0121 Rod Brooks <ROD at SU-AI> DO loses.
C00144 00019 ∂22-Feb-82 1241 2Lt Eric J. Swenson <EJS at MIT-MC> Interlisp and MacLisp (almost)
C00146 00020 ∂22-Feb-82 1337 Glenn S. Burke <GSB at MIT-ML> DO loses.
C00150 00021 ∂23-Feb-82 2026 George J. Carrette <GJC at MIT-MC> Closing Files.
C00151 00022 ∂26-Feb-82 1319 FEINBERG at CMU-20C DSK:
C00152 00023 ∂27-Feb-82 1153 EB@MIT-ML
C00153 00024 ∂27-Feb-82 1153 Jon L White <JONL at MIT-MC>
C00155 00025 ∂27-Feb-82 1247 Jon L White <JONL at MIT-MC> Compilation bug seen in DO loop
C00174 00026 ∂06-Mar-82 1904 Alan Bawden <ALAN at MIT-ML> how am I supposed to deal with this behavior?
C00176 00027 ∂08-Mar-82 0755 Jon L White <JONL at MIT-MC> Wrong result
C00181 00028 ∂08-Mar-82 1629 FEINBERG at CMU-20C Restricted JFNs
C00190 00029 ∂16-Mar-82 1643 George J. Carrette <GJC at MIT-MC>
C00191 00030 ∂23-Mar-82 1309 John G. Aspinall <JGA at MIT-MC> fixing, flooring, ceiling,...
C00193 00031 ∂11-Apr-82 1340 Glenn S. Burke <GSB at MIT-ML> assq compatibility with Maclisp
C00212 00032 ∂20-Apr-82 1831 Alan Bawden <ALAN at MIT-MC> &mumbles at all levels.
C00218 00033 ∂21-Apr-82 2203 JonL at PARC-MAXC Re: &mumbles at all levels -- BIND-ARGS
C00220 00034 ∂22-Apr-82 1136 George J. Carrette <GJC at MIT-MC> &mumbles at all levels.
C00222 00035 ∂22-Apr-82 1324 Stavros M. Macrakis <MACRAK at MIT-MC>
C00223 00036 ∂22-Apr-82 1614 Stavros M. Macrakis <MACRAK at MIT-MC>
C00229 00037 ∂02-May-82 2117 REM via SU-TIP (SSTATUS GCMAX 'ARRAY <n>) still not working
C00234 00038 ∂03-May-82 2054 Kent M. Pitman <KMP at MIT-MC>
C00236 00039 ∂05-May-82 1853 Leonard N Zubkoff <Zubkoff at Cmu-20c> Changes to Maclisp
C00239 00040 ∂05-May-82 2007 FEINBERG at CMU-20C Changes to Maclisp
C00241 00041 ∂06-May-82 1046 JONL at PARC-MAXC Of%Pdt
C00243 00042 ∂10-May-82 1215 OTADUY PEDRO J. <PJO at MIT-MC>
C00247 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂03-Apr-81 0610 JerryB at MIT-AI (Gerald R. Barber) Improving the LISP working environment by taking a lesson from...
Date: 3 APR 1981 0908-EST
From: JerryB at MIT-AI (Gerald R. Barber)
Subject: Improving the LISP working environment by taking a lesson from...
To: SHRAGE at WHARTON-10, Deutsch at PARC-MAXC
CC: LISP-FORUM at MIT-AI, nil at MIT-MC
Date: 10 Nov 1980 10:41 PST
From: Deutsch at PARC-MAXC
To: SHRAGE at WHARTON (Jeffrey Shrager)
cc: lisp-forum, nil at MIT-MC
Re: Improving the LISP working environment by taking a lesson from...
1- In Interlisp, the Masterscope facility lets you easily find out what all your
functions, variables, etc. names are. In fact, it includes a powerful query
facility for discovering relationships in your program, much better than
anything in any other language or system I know. It is callable both from the
terminal (with pleasant English-like syntax) or from programs.
2- The SYSOUT facility in Interlisp makes it very cheap (in time) to create
checkpoints which you can resume from later. Many Interlisp users prefer the
APL "workspace" style, keeping a SYSOUT around to work in for days or weeks.
3- It's not simply a matter of "cover functions", different Lisp systems have
chosen to develop themselves in quite different directions. For example, Interlisp
has put tremendous emphasis on managing the programming process through
history retention, building up a data base of your code, etc., while MACLisp has
placed more emphasis on efficient compilation and certain kinds of system
simplicity. APL hasn't grown in ANY of these directions as far as I know. To
quote Joel Moses (approximately): "APL is a diamond -- you can't add anything
to it, even another diamond, without ruining its beauty. Lisp is a ball of mud:
you can keep adding more and more mud to it and its nature doesn't change." I
think it is precisely because Lisp is really almost like an assembly language for a
particularly interesting machine that it has been used to do such a tremendous
variety of things.
Here is a copy of a message that may be of interest.
∂18-Jun-81 2147 Richard M. Stallman <RMS at MIT-AI> nested function definitions interfering with extensibility.
Date: 19 June 1981 00:44-EDT
From: Richard M. Stallman <RMS at MIT-AI>
Subject: nested function definitions interfering with extensibility.
To: LISP-FORUM at MIT-AI
Date: 18 June 1981 10:37-EDT
From: George J. Carrette <GJC at MIT-MC>
This certainly true in the case of program editing in a
non-structured text-oriented way, but in a system with
more cooperation between program editor and compiler this
need not be the case. I'm all for editing programs as text,
but I don't like representing them, storing them, as
a sequence of characters, i.e. in a purely syntactic manner.
Why? Because it severely limits program management to
purely syntactical levels.
The problem is not in editing at all. It is easy in any sort of
editor to edit the internal function definition and make no change to
the external one, and vice versa.
The problem comes when you try to store a file which, when loaded,
changes one but not the other. No editing is involved, just loading
of source or compiled files.
IRT Moon's suggestion:
Function specs like (:INTERNAL FOO BAR) for BAR within FOO make it
possible to redefine the internal function without changing the
external one. This is a good solution for that half of the problem.
But how do you redefine the external one without changing the internal
one?
∂28-Sep-81 0617 Mark L. Miller <MILLER at MIT-AI> Suggested new lambda-list syntax
Date: 28 September 1981 09:07-EDT
From: Mark L. Miller <MILLER at MIT-AI>
Subject: Suggested new lambda-list syntax
To: RMS at MIT-AI
cc: LISP-FORUM at MIT-AI
I prefer this proposal to the existing situation. Regards, Mark
∂11-Jan-82 0932 George J. Carrette <GJC at MIT-MC> backquote trivia, for you history fans.
Date: 11 January 1982 12:21-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: backquote trivia, for you history fans.
To: Morrison at UTAH-20
cc: Lisp-Forum at MIT-AI
The PDP-10 Maclisp implementation of Backquote works at macroexpansion
time as you wanted. This was done for ease of GRINDEF'ing.
The Lispmachine implementation provides special synonyms for LIST, CONS,
LIST*, APPEND, etc, and uses a simple pattern matcher to create a cannonical
pretty form for GRINDEF. The NIL implementation uses code lifted from
code from which the Multics Maclisp backquote was derived, which is also
related in some way to the Lispmachine backquote.
In all implementations there are "car-position" markers for "," ",@" and ",."
and some simple entry to the "BACKQUOTIFY" function called by "`"
either at read or eval times.
Q: What is the deepest nesting of backquote found to arise in practice?
-gjc
∂11-Jan-82 0939 HES@MIT-AI
From: HES@MIT-AI
Date: 01/11/82 12:25:08
HES@MIT-AI 01/11/82 12:25:08
To: (BUG COMPLR) at MIT-AI
CC: ALAN at MIT-AI
The maclisp complr seems to generate the wrong stuff for the
code in ai:reason;foobar > ; in particluar the form
(setf (tms-support-status node) *in*)
turns into the wrong thing. Note that this code works interpretively.
My complr init loads lisp;struct fasl as does my lisp init in case this is relevant.
howie
∂11-Jan-82 1551 Don Morrison <Morrison at UTAH-20> clarification regarding backquote query
Date: 11 Jan 1982 1601-MST
From: Don Morrison <Morrison at UTAH-20>
Subject: clarification regarding backquote query
To: lisp-forum at MIT-AI
The sort of thing I had in mind for a complicated macro producing macro
was to have a macro producing macro foo consing up the final form, but
bits and pieces it stuffs in are being created by a function bar. The
value which foo finally returns will be some hairy conglomeration of
conses, lists, and appends, such as backquote is particularly good at
creating. But the pieces which bar creates will mostly be constant,
but sometimes I'd like bar to be able to return a piece which contains
a call on unquote, which unquote will be seen by the dynamically
surrounding backquote (i.e. in foo), rather than a lexically
surrounding one. Perhaps this is too complicated to be done clearly
(this description certainly is so complicated that I doubt it would
ever be clear) with backquote, but I seem to remember having created
such a beast where this seemed more perspicuous than the hard way.
Unfortunately I can't remember the exact example, and all the examples
I can now dream up don't warrant such a procedure; seems that in all my
toy examples simply adding an unquote in the caller and a backquote in
the callee works. Perhaps the "dynamic version" is never really
useful. And anyway, I gather from some of the replies that there are
functional entry points to the required pieces available in MACLISP and
friends, though I still don't know their names.
-------
∂12-Jan-82 1446 Jon L White <JONL at MIT-MC> 'backquote' actions
Date: 12 January 1982 17:38-EST
From: Jon L White <JONL at MIT-MC>
Subject: 'backquote' actions
To: Morrison at UTAH-20
cc: LISP-FORUM at MIT-MC
In MacLISP, the variable BACKQUOTE-EXPAND-WHEN determines
whether the reader-macro produces a minimal, standard, lisp form
which merely 'evaluates to the right thing', or a form with extra
evaluator macros inserted which correspond to the places where 'commas'
of various kinds appeared. Of course, the latter format 'evaluates
to the right thing' too.
The LISPM version produces a rather minimal form for evaluation, but using
internal function names rather than the standard lisp ones.
The point of having either the extra evaluator macros, or the special
internal function names, is so that a random piece of code which was
constructed up by the backquote macro can be re-parsed into a faithful
representation of the original input. The advantage of using evaluator
macros as opposed to internal subrs is that automatic code analyzers
don't have to know about these internal names (but rather would only
have to know about macroexpansion in general and the usual primitive
lisp subrs); the disadvantage of using the evaluator macro format is
that it takes an extra cons cell or so for each comma in the source input.
Note for example that there currently is no way to distinguish between the
internal forms of the following two functions:
(defun FIVE+ONE (x) '6)
(defun SIX (x) (quote 6))
whereas
(defun QUOTIFY-1 (x) `',x)
(defun QUOTIFY-2 (x) (list (quote QUOTE) x))
are distinguishable when BACKQUOTE-EXPAND-WHEN is set to EVAL (or
when other internal markers are left in).
∂16-Jan-82 1132 William G. Dubuque <WGD at MIT-MC>
Date: 16 January 1982 14:32-EST
From: William G. Dubuque <WGD at MIT-MC>
Sender: BIL at MIT-MC
To: BUG-LISP at MIT-MC
The VECTOR package seems to break LEXPR-FUNCALL, e.g.
(load '((lisp)vector))
(lexpr-funcall 'list ()) =>
;SI:CLASS-TYPEP UNDEFINED FUNCTION IN UUO CALL
∂25-Jan-82 2316 FININ at WHARTON-10 (Tim Finin) Interlisp and MacLisp (almost)
Date: 26 Jan 1982 (Tuesday) 0211-EDT
From: FININ at WHARTON-10 (Tim Finin)
Subject: Interlisp and MacLisp (almost)
To: ejs at MIT-MC
cc: lisp-forum at MIT-MC
I've been working on a general inter-dialect Lisp translation system which
specializes in Interlisp to Franz Lisp (which is very close to MacLisp). It
is still undergoing developement. It includes a general rule driven
translator, a small set of pattern-action rules for translating Interlisp into Franz,
and a Interlispy run time environment for Frnaz. At Penn, we've opted for
a system that includes both translation and emulation. Some other efforts
I'm aware of include the following:
- The Franz group at Berkeley have some sort of Interlisp compatability
package for Franz.
- An extensive Interlisp to MacLisp translation system called MACLISPIFY
was written at SRI and used to transport some large systems. I can dig
up the details if you're interested.
- The Interlisp system includes the TRANSOR package for trnaslating Interlisp
code to other Lisp dialects. There is a set of rules for Interlisp to Maclisp,
although it is somewhat dated.
- There was a Interlisp to Maclisp translation system written by Jack Holloway
(I believe) and extended by Dave McDonnald. It was used to translate
the LUNAR system to MacLisp and LispMachine Lisp (I think).
- There is a group at Stanford on SUMEX that is trying to implement some of
the Interlisp packages (e.g. the RECORD package) in Franz.
i can supply more details on some of these efforts if you are interested.
Tim
∂30-Jan-82 0728 kwh@MIT-AI minilisp
From: kwh@MIT-AI
Date: 01/30/82 10:20:21
Subject: minilisp
kwh@MIT-AI 01/30/82 10:20:21 Re: minilisp
To: lisp-forum at MIT-MC, JoSH at RUTGERS
CC: KWH at MIT-AI
Bob Kirby at the University of Maryland has a nice LISP for the 11- it is a derivative
of Maryland LISP (which runs on UNIVAC's) which is derivative from Wisconson LISP...
It has a pretty printer, a MICROPLANNER, a structure editor, and a bunch of other
stuff. Bob Kirby is in the computer science department at Maryland, so you might
want to get in touch with him- the only problem with any LISP's for the 11 is that
you are intrinsically limited by that address space- (unless you hack
virtual memory, which is hairy but possible....)
Good luck,
Ken.
p.s. Does MIT have a copy of Rutger's extended addressing LISP? Can we get
one? Is there any documentation for it I could get a copy of?
∂30-Jan-82 1405 Jon L White <JONL at MIT-MC> Comparison of "lambda-macros" and my "Two little suggestions ..."
Date: 30 January 1982 16:55-EST
From: Jon L White <JONL at MIT-MC>
Subject: Comparison of "lambda-macros" and my "Two little suggestions ..."
To: KMP at MIT-MC, hic at SCRC-TENEX
cc: LISP-FORUM at MIT-MC, common-lisp at SU-AI
[Apologies for double mailings -- could we agree on a name for a
mailing list to be kept at SU-AI which would just be those
individuals in COMMON-LISP@SU-AI which are not also on LISP-FORUM@MC]
There were two suggestions in my note, and lambda-macros relate
to only one of then, namely the first one
FIRST SUGGESTION:
In the context of ((<something> . . .) a1 a2), have EVAL macroexpand
the part (<something> . . .) and "try again" before recursively
evaluating it. This will have the incompatible effect that
(defmacro foo () 'LIST)
((foo) 1 2)
no longer causes an error (unbound variable for LIST), but will rather
first expand into (list 1 2), which then evaluates to (1 2).
Note that for clarity, I've added the phrase "try again", meaning to
look at the form as see if it is recognized explicitly as, say, some
special form, or some subr application.
The discussion from last year, which resulted in the name "lambda-macros"
centered around finding a separate (but equal?) mechanism for code-expansion
for non-atomic forms which appear in a function place; my first suggestion
is to change EVAL (and compiler if necessary) to call the regular macroexpander
on any form which looks like some kind of function composition, and thus
implement a notion of "Meta-Composition" which is context free. It would be
a logical consequence of this notion that eval'ing (FUNCTION (FROTZ 1)) must
first macroexpand (FROTZ 1), so that #'(FPOSITION ...) could work in the
contexts cited about MAP. However, it is my second suggestion that would
not work in the context of an APPLY -- it is intended only for the EVAL-
of-a-form context -- and I'm not sure if that has been fully appreciated
since only RMS appears to have alluded to it.
However, I'd like to offer some commentary on why context-free
"meta-composition" is good for eval, yet why context-free "evaluation"
is bad:
1) Context-free "evaluation" is SCHEME. SCHEME is not bad, but it is
not LISP either. For the present, I believe the LISP community wants
to be able to write functions like:
(DEFUN SEMI-SORT (LIST)
(IF (GREATERP (FIRST LIST) (SECOND LIST))
LIST
(LIST (SECOND LIST) (FIRST LIST))))
Correct interpretation of the last line means doing (FSYMEVAL 'LIST)
for the instance of LIST in the "function" position, but doing (more
or less) (SYMEVAL 'LIST) for the others -- i.e., EVAL acts differently
depending upon whether the context is "function" or "expression-value".
2) Context-free "Meta-composition" is just source-code re-writing, and
there is no ambiguity of reference such as occured with "LIST" in the
above example. Take this example:
(DEFMACRO GET-SI (STRING)
(SETQ STRING (TO-STRING STRING))
(INTERN STRING 'SI))
(DEFUN SEE-IF-NEW-ATOM-LIST (LIST)
((GET-SI "LIST") LIST (GET-SI "LIST")))
Note that the context for (GET-SI "LIST") doesn't matter (sure, there
are other ways to write equivalent code but . . .)
Even the following macro definition for GET-SI results in perfectly
good, unambiguous results:
(DEFMACRO GET-SI (STRING)
`(LAMBDA (X Y) (,(intern (to-string string) 'SI) X Y)))
For example, assuming that (LAMBDA ...) => #'(LAMBDA ...),
(SEE-IF-NEW-ATOM-LIST 35) => (35 #'(LAMBDA (X Y) (LIST X Y)))
The latter (bletcherous) example shows a case where a user ** perhaps **
did not intend to use (GET-SI...) anywhere but in function context --
he simply put in some buggy code. The lambda-macro mechanism would require
a user to state unequivocally that a macro-defintion in precisely one
context; I'd rather not be encumbered with separate-but-parallel machinery
and documentation -- why not have this sort of restriction on macro usage
contexts be some kind of optional declaration?
Yet my second suggestion involves a form which could not at all be interpreted
in "expression-value" context:
SECOND SUGGESTION
Let FMACRO have special significance for macroexpansion in the context
((FMACRO . <fun>) . . .), such that this form is a macro call which is
expanded by calling <fun> on the whole form.
Thus (LIST 3 (FMACRO . <fun>)) would cause an error. I believe this
restriction is more akin to that which prevents MACROs from working
with APPLY.
∂30-Jan-82 1446 Jon L White <JONL at MIT-MC> The format ((MACRO . f) ...)
Date: 30 January 1982 17:39-EST
From: Jon L White <JONL at MIT-MC>
Subject: The format ((MACRO . f) ...)
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
HIC has pointed out that the LISPM interpreter already treats the
format ((MACRO . f) ...) according to my "second suggestion" for
((FMACRO . f) ..); although I couldn't find this noted in the current
manual, it does work. I'd be just as happy with ((MACRO . f) ...) -- my
only consideration was to avoid a perhaps already used format. Although the
LISPM compiler currently barfs on this format, I believe there will be a
change soon?
The issue of parallel macro formats -- lambda-macros versus
only context-free macros -- is quite independent; although I
have a preference, I'd be happy with either one.
∂01-Feb-82 0752 Jon L White <JONL at MIT-MC> Incredible co-incidence about the format ((MACRO . f) ...)
Date: 1 February 1982 10:47-EST
From: Jon L White <JONL at MIT-MC>
Subject: Incredible co-incidence about the format ((MACRO . f) ...)
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
One of my previous messages seemed to imply that ((MACRO . f) ...)
on the LISPM fulfills the intent of my second suggestion -- apparently
there is a completely unforseen consequence of the fact that
(FSYMEVAL 'FOO) => (MACRO . <foofun>)
when FOO is defined as a macro, such that the interpreter "makes it work".
However, MACROEXPAND knows nothing about this format, which is probably
why the compiler can't handle it; also such action isn't documented
anywhere.
Thus I believe it to be merely an accidental co-incidence that the
interpreter does anything at all meaningful with this format. My
"second suggestion" now is to institutionalize this "accident"; it
certainly would make it easier to experiment with a pseudo-functional
programming style, and it obviously hasn't been used for any other
meaning.
∂01-Feb-82 0847 HIC at SCRC-TENEX Incredible co-incidence about the format ((MACRO . f) ...)
Date: Monday, 1 February 1982 11:38-EST
From: HIC at SCRC-TENEX
To: Jon L White <JONL at MIT-MC>
Cc: common-lisp at SU-AI, LISP-FORUM at MIT-MC
Subject: Incredible co-incidence about the format ((MACRO . f) ...)
Date: Monday, 1 February 1982 10:47-EST
From: Jon L White <JONL at MIT-MC>
To: common-lisp at SU-AI
cc: LISP-FORUM at MIT-MC
Re: Incredible co-incidence about the format ((MACRO . f) ...)
One of my previous messages seemed to imply that ((MACRO . f) ...)
on the LISPM fulfills the intent of my second suggestion -- apparently
there is a completely unforseen consequence of the fact that
(FSYMEVAL 'FOO) => (MACRO . <foofun>)
when FOO is defined as a macro, such that the interpreter "makes it work".
However, MACROEXPAND knows nothing about this format, which is probably
why the compiler can't handle it; also such action isn't documented
anywhere.
Of course MACROEXPAND knows about it (but not the version you looked
at). I discovered this BUG (yes, BUG, I admit it, the LISPM had a
bug) in about 2 minutes of testing this feature, after I told the
world I thought it would work, and fixed it in about another two
minutes.
Thus I believe it to be merely an accidental co-incidence that the
interpreter does anything at all meaningful with this format. My
"second suggestion" now is to institutionalize this "accident"; it
certainly would make it easier to experiment with a pseudo-functional
programming style, and it obviously hasn't been used for any other
meaning.
JONL, you seem very eager to make this be your proposal -- so be it.
I don't care. However, it works on the Lisp Machine (it was a BUG
when it didn't work) to have (MACRO . foo) in the CAR of a form, and
thus it works to have a lambda macro expand into this.
Of course, Lambda Macros are the right way to experiment with the
functional programming style -- I think it's wrong to rely on seeing
the whole form (I almost KNOW it's wrong...). In any case, the Lisp
Machine now has these.
∂17-Feb-82 2001 Jon L White <JONL at MIT-MC> SHARPM
Date: 17 February 1982 20:13-EST
From: Jon L White <JONL at MIT-MC>
Subject: SHARPM
To: ALAN at MIT-MC, GSB at MIT-MC
cc: BUG-LISP at MIT-MC
The additions to SHARPM which I mentiond about a month or so ago
are now installed in version 82 --
1) #nRddd format now works
2) #|...cruft...|# format now works, as per ALAN's request
3) the actual format of the /#-MACRO-DATALIST has been changed --
be advised if you ever depended upon it.
This change is only on MC right now, but I'll :INSTALL it "soon".
If anyone needs to back out of it, you should move LISP;SHARPM OFASL
into LISP;SHARPM FASL.
NOTE WELL: this change must correspondingly be coordinated with
the installation of EXTEND (from version 291 to 292), BITS (from
version 45 to 46), and VECTOR (from version 73 to 74) -- thus
an un-doing of SHARPM must also install LISP;* OFASL into LISP;* FASL
for these three files (for efficiency reasons, they depend upon
the format of that list).
∂22-Feb-82 0121 Rod Brooks <ROD at SU-AI> DO loses.
Date: 22 Feb 1982 0120-PST
From: Rod Brooks <ROD at SU-AI>
Subject: DO loses.
To: bug-complr at MIT-MC
I can't remember if this is a manifestation of a bug that bit me a couple
of times a few years ago, and which JONL said was too hard to fix, but
it sure surprised me. The only difference between foo and baz below is the
order of their supposedly side-effectless do steppers. I couldn't get it
to lose cdr-ing down a list, rather than using the array.
(*array 'arr 'fixnum 6)
(fillarray 'arr '(8 7 6 5 4 3 2))
(setq arr (get 'arr 'array))
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0)
(arraycall fixnum l i)))
((= i 5))
(print (list ch last))))
(defun baz (l)
(do ((i 1 (1+ i))
(ch (arraycall fixnum l 0)
(arraycall fixnum l i))
(last 0 ch))
((= i 5))
(print (list ch last))))
.lisp
LISP 2133
Alloc? n
*
(fasload lose fas)
34121
(foo arr)
(10 0)
(7 10)
(6 6)
(5 5) NIL
(baz arr)
(10 0)
(7 10)
(6 7)
(5 6) NIL
∂22-Feb-82 1241 2Lt Eric J. Swenson <EJS at MIT-MC> Interlisp and MacLisp (almost)
Date: 22 February 1982 15:35-EST
From: 2Lt Eric J. Swenson <EJS at MIT-MC>
Subject: Interlisp and MacLisp (almost)
To: FININ at WHARTON-10
cc: LISP-FORUM at MIT-MC
Thanks for all your help with respect to Interlisp to Maclisp translators.
I am forwarding your message to ZHARTMAN@ISIE who works with the folks who
are interested in this endeavor. I'll let them handle it from there. I
would, however, like to saty in touch with the discussion, so please CC
your responses to their questions to me. Thanks. Also, I am interested in
the SRI project used to transport large systems. Please give me any
pointers to relevant information. Thanks -- Eric
∂22-Feb-82 1337 Glenn S. Burke <GSB at MIT-ML> DO loses.
Date: 22 February 1982 16:31-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: DO loses.
To: ROD at SU-AI
cc: BUG-complr at MIT-MC
Yes, this is that old hard-to-fix bug. The insertion of type declarations,
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0) (arraycall fixnum l i)))
((= i 5))
--> (declare (fixnum i last ch))
(print (list ch last))))
causes it to perform correctly. As a general rule declarations
for known-fixnum quantities, most especially inside loops as these
are, both stifle this bug and produce better code.
∂23-Feb-82 2026 George J. Carrette <GJC at MIT-MC> Closing Files.
Date: 23 February 1982 23:25-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: Closing Files.
To: FEINBERG at CMU-20C
cc: BUG-MACLISP at MIT-MC
For your information: File objects get closed when they are sweeped by
the garbage collector.
So all you need to do is have Emacs cause a GC in your Lisp job (or
any other Lisp job that has your file open)!
∂26-Feb-82 1319 FEINBERG at CMU-20C DSK:
Date: 26 February 1982 16:08-EST (Friday)
From: FEINBERG at CMU-20C
To: Bug-Maclisp at MC
Subject: DSK:
Howdy!
What is the status of fixing the the bug where someone
redefines DSK: to a list of things, and then Maclisp breaks? Another
user has just been screwed by this.
∂27-Feb-82 1153 EB@MIT-ML
From: EB@MIT-ML
Date: 02/27/82 12:58:24
EB@MIT-ML 02/27/82 12:58:24
To: JONL at MIT-MC
CC: (BUG MACLISP) at MIT-ML
ARYFIL and such are all very nice, but why does it use restricted
JFN's in the first place?????
∂27-Feb-82 1153 Jon L White <JONL at MIT-MC>
Date: 27 February 1982 13:28-EST
From: Jon L White <JONL at MIT-MC>
To: eb at MIT-ML
cc: BUG-MACLISP at MIT-MC, feinberg at CMU-20C
EB@MIT-ML 02/27/82 12:58:24
ARYFIL and such are all very nice, but why does it use restricted
JFN's in the first place?????
They aren't "restricted" -- they are "frozen" accesses. I suspect that
Feinberg was confused. "Frozen" means that any number of readers can gain
access, but at most one writer can have APPEND access (I don't think you
can get random write access from within LISP). A file opened for ordinary
write access isn't visible in the catalogue until it is closed; maybe
that's what caused Feinberg to think it was "restricted". Any comments Neal?
P.S.: I'm using version 2129 at MIT-XX -- I notice that CMUC still has version
2122 from last fall; hopefully this won't make a diference, but I'll
send a note to Zubkoff to suggest the possibility of an update for CMUC.
∂27-Feb-82 1247 Jon L White <JONL at MIT-MC> Compilation bug seen in DO loop
Date: 27 February 1982 15:05-EST
From: Jon L White <JONL at MIT-MC>
Subject: Compilation bug seen in DO loop
To: ROD at MIT-MC
cc: BUG-COMPLR at MIT-MC
Yes, the bug you noticed in "baz" below is a manifestation of the
local-variable-side-effected-by-fixnum-value bug, which you (and
a handful of others, notably GLR) discovered some time ago. The
simplest way to avoid this COMPLR problem is to declare such local
variable as FIXNUM, since it is the lack such declaration which
permits the bug to be seen; I've added a DECLARE in caps below to
indicate it. The declaration isn't necessary in "foo" since the
side-effects don't occur at the wrong time there, but it won't hurt
anything by having it (may even make the code marginally faster).
Date: 22 Feb 1982 0120-PST
From: Rod Brooks <ROD at SU-AI>
. . .
(defun foo (l)
(do ((i 1 (1+ i))
(last 0 ch)
(ch (arraycall fixnum l 0)
(arraycall fixnum l i)))
((= i 5))
(DECLARE (FIXNUM CH))
(print (list ch last))))
(defun baz (l)
(do ((i 1 (1+ i))
(ch (arraycall fixnum l 0)
(arraycall fixnum l i))
(last 0 ch))
((= i 5))
(DECLARE (FIXNUM CH))
(print (list ch last))))
∂06-Mar-82 1904 Alan Bawden <ALAN at MIT-ML> how am I supposed to deal with this behavior?
Date: 6 March 1982 22:04-EST
From: Alan Bawden <ALAN at MIT-ML>
Subject: how am I supposed to deal with this behavior?
To: BUG-COMPLR at MIT-ML
(defun test (x y)
(declare (fixnum x y))
(plus x y))
compiles into:
(LAP TEST SUBR)
(ARGS TEST (() . 2))
(MOVE 7 0 1)
(ADD 7 0 2)
(JSP T FXCONS)
(POPJ P)
()
This is incorrect. Nowhere did I specify that the sum of x and y was a fixnum
too.
Similarly:
(defun test (x y)
(plus (1+ x) (1+ y)))
Compile into:
(LAP TEST SUBR)
(ARGS TEST (() . 2))
(MOVE 7 0 1)
(ADDI 7 1)
(MOVE 10 0 2)
(ADDI 10 1)
(ADD 7 10)
(JSP T FXCONS)
(POPJ P)
()
Same bug.
∂08-Mar-82 0755 Jon L White <JONL at MIT-MC> Wrong result
Date: 8 March 1982 10:51-EST
From: Jon L White <JONL at MIT-MC>
Subject: Wrong result
To: JSOL at USC-ECLC
cc: BUG-MACLISP at MIT-MC, Feinberg at CMU-20C
Date: Friday, 5 March 1982 09:19-PST
From: Jonathan Alan Solomon <JSOL at ECLC>
Subject: Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN
Seems to me that you can do it without "restricting the JFN". If you
open the file "restricted access", which uses the following bit
(excerpt from INFO's JSYS node):
B29(OF%RTD) Allow restricted access (i.e., allow
only one process to access the file).
You will get the desired results (no other process can hack the file),
while at the same time, INFORMATION (ABOUT) FILE will show it. Note,
this is for the OPENF jsys, not for the GTJFN jsys. The JFN is
available, but the file is locked.
I believe that what was desired was that the JFN be "protected" from
mungeing by random subforks, but that the file access *not* be restricted.
That is, it's ok for several forks/jobs to open the file for simultaneous
reading; the "frozen" access, by default, prohibits more than one user at
a time from gaining write/append access.
∂08-Mar-82 1629 FEINBERG at CMU-20C Restricted JFNs
Date: 8 March 1982 19:26-EST (Monday)
From: FEINBERG at CMU-20C
Subject: Restricted JFNs
To: Jonl at MC
CC: Bug-Maclisp at MC, Bug-Twenex at XX
Howdy!
Sorry, but you are inaccurate about Teco. Teco does indeed
have subforking capability (the FZ command). It uses this capability
to make Babyl work, and to make spelling correction possible. In
almost every case of the GTJFN command, you never specify the JFN
number you want, it finds a free JFN for you. I don't understand your
paranoia about this issue, however I feel a compromise can be reached.
Why not have a global flag which determines whether or not Maclisp
should use restricted JFNs? The default can even be paranoia mode.
This is very easy to implement efficiently. The only other objection
I can see for this is that no one wants to write the code for it. In
that case, I would be glad to implement this feature. ARYFIL is just
not an acceptable solution for me, and I am willing to do something
about it. I am not the only person who wants this fixed, either.
∂16-Mar-82 1643 George J. Carrette <GJC at MIT-MC>
Date: 16 March 1982 19:42-EST
From: George J. Carrette <GJC at MIT-MC>
To: SOLEY at MIT-MC, DCP at MIT-MC
cc: BUG-LISP at MIT-MC
Do you guys really expect to see bugs in the Maclisp reader fixed?
Geeeezzzz, I don't believe it. You can always write one yourself in
lisp, load EE:<GJC.LISP>READER.FASL, but then the tty-prescan won't
jive, so load KMP's rubout handler from EE:<GJC.LISP>RUB.FASL.
Don't like the evaluator? Well, replace that too.
Keep it up, and you soon run out of core.
∂23-Mar-82 1309 John G. Aspinall <JGA at MIT-MC> fixing, flooring, ceiling,...
Date: 23 March 1982 16:07-EST
From: John G. Aspinall <JGA at MIT-MC>
Subject: fixing, flooring, ceiling,...
To: BUG-LISP at MIT-MC
About a year or two ago I remember a discussion on LISP-DISCUSSION
about the various rounding functions, and a suggestion that someone
implement the set for MacLisp. There was a standard (IEEE ?) that
specified them. Was this ever done?
To remind - round towards zero : fix
- round towards -infinity : floor
- round towards +infinity : ceiling
- round away from zero : <I forget this one.>
John.
∂11-Apr-82 1340 Glenn S. Burke <GSB at MIT-ML> assq compatibility with Maclisp
Date: 11 April 1982 16:37-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: assq compatibility with Maclisp
To: JCMA at MIT-AI, BUG-lisp at MIT-MC
cc: BUG-LISPM at MIT-AI
Date: Saturday, 10 April 1982, 06:04-EST
From: JCMA@MIT-AI
Why do assq and assoc have to be incompatible with maclisp? That is,
why aren't assoc-careful and assq-careful the defaults?
----
It happens that Maclisp does not actually do assq-carefully, at least
not deliberately. It simply fails to check, and so can be fooled.
---- [transition to bug-lisp report] ----
uh oh... Even though i "knew" what maclisp was doing, i figured that
i would test it to see. The little cretin does assq-carefully in
(*RSET T) mode, and doesn't in (*RSET NIL) mode. What this means is
that the following happens in (*rset nil)
(assq nil '(0)) => 0
and in (*rset t) it yields NIL. The reason for this is that the CAR of
the fixnum 0 gives NIL. Similarly one can create other fixnums (and flonums)
which will fool assq for any other object.
So much for features. This sounds like a totally useless, misleading,
and inconsistent Maclisp feature. It is a waste of the address space
which someone has been trying hard to conserve. If it is going to check,
it should bitch, it shouldn't conditionally do the wrong thing.
∂20-Apr-82 1831 Alan Bawden <ALAN at MIT-MC> &mumbles at all levels.
Date: 20 April 1982 21:27-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: &mumbles at all levels.
To: BUG-LISPM at MIT-MC
cc: LISP-FORUM at MIT-MC, DULCEY at MIT-ML
Date: 04/19/82 22:30:38
From: DULCEY at MIT-ML
(defmacro foo ((one &optional (two ''two)) &body three)
`(list ,one ,two ',three))
>>ERROR: &OPTIONAL -- unrecognized & keyword in DEFMACRO.
While in the function ...
This probably isn't defined as working. However, it would be useful if
it did.
Indeed, this is currently defined to be an error. Would anyone object if I
actually made it act as it obviously should? I would like to fix this, and
simultaneously introduce a general tool for performing macro body parsing.
Proposed new special form: BIND-ARGUMENTS
example:
(bind-arguments ((a &optional (b *b*)) (foo) (barf))
b o d y)
(approximately)==>
(let ((gensym (foo)))
(if (not (and (<= (length gensym) 2)
(>= (length gensym) 1)))
(barf))
(let ((a (car gensym))
(b (if (< (length gensym) 2) *b* (cadr gensym))))
b o d y))
Now, you probably would never need a macro like this directly, but suppose you
had to write defmacro yourself:
(defmacro defmacro (name pattern &body body)
(let ((v (gensym)))
`(macro ,name (,v)
(bind-arguments (,pattern (cdr ,v) (ferror nil "Bad syntax: ~S" ,v))
,@body))))
That was easy wasn't it! So easy that ANYONE can do it. This seems to be the
right tool for bringing &mumble-argument-parsing to the masses.
Now I already have a working one of these (amazingly usefull in the right
situations I must add), and I would like to install it in the LispMachine as
the way defmacro etc work. This would have two noticeable effects:
1) &keywords would start to work at all levels in defmacro patterns. I presume
no one objects to this?
2) &list-of STOPS working... (finally I got around to the screw). Does ANYONE
use this feature? I could try and duplicate it, but if noone uses it (as I
suspect) I would rather just flush it. What to LispMachine people think?
(If no one raises objection, I'll ask info-lispm next.)
Unnoticeable effect:
3) The code produced by defmacro would be smaller and faster. (You would be
appalled at the code defmacro currently turns out.)
∂21-Apr-82 2203 JonL at PARC-MAXC Re: &mumbles at all levels -- BIND-ARGS
Date: 21 Apr 1982 21:57 PST
From: JonL at PARC-MAXC
Subject: Re: &mumbles at all levels -- BIND-ARGS
In-reply-to: ALAN's message of 20 April 1982 21:27-EST
To: Alan Bawden <ALAN at MIT-MC>
cc: Guy.Steele@CMUA,LISP-FORUM@MIT-MC
Wasn't there a lot of discussion about 6 months to a year ago about
having LET accept &mumbles "at lots of levels"? When you say
"at all levels" do you mean that BIND-ARGS will also destructure?
If progress on LET is going to be forever bogged down in the red tape,
then how about doing BIND-ARGUMENTS at least one of the two ways
proposed for destructuring (and since you are using the &optional words,
you have more-or-less selected the data-pattern format rather than the SETF
format).
∂22-Apr-82 1136 George J. Carrette <GJC at MIT-MC> &mumbles at all levels.
Date: 22 April 1982 14:31-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: &mumbles at all levels.
To: ALAN at MIT-MC
cc: BUG-LISPM at MIT-MC, LISP-FORUM at MIT-MC, BUG-LISP at MIT-MC,
DULCEY at MIT-ML
Go for it! Indeed, for the destructuring implementation for NIL I
implemented &mumbles at all levels, and it was easier, cleaner, and
produced considerably less code per DEFMACRO than using the other
methods.
For example, the following defmacro:
(defmacro g ((a b (c d)) &optional e)
(foo a b c d e))
compiles into 42 pdp-10 instructions using the technology presently
provided in Maclisp, but only 7 pdp-10 instructions using the technology used
in NIL (inside the compilation environment in pdp-10 maclisp which *was* used
to compile the cross compiler).
-gjc
∂22-Apr-82 1324 Stavros M. Macrakis <MACRAK at MIT-MC>
Date: 22 April 1982 16:24-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
To: BUG-COMPLR at MIT-MC
(defun f (a b)
(let ((x (f1 a)) (y (f2 a)))
(cond ((not x) y)
((eq x y) y)
((eq y x) y)
((eq x y) x)
((eq y x) x)))))))
(which admittedly is weird code) produces a whole succession of code
sequences like:
caxx
jrst g1
jrst g2
g1:
while the same code without the Let doesn't.
∂22-Apr-82 1614 Stavros M. Macrakis <MACRAK at MIT-MC>
Date: 22 April 1982 19:11-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
To: BUG-COMPLR at MIT-MC
(defun sdfsdf (wer) (cond ((null wer) nil)))
compiles to
push p,1
sub p,[1,,1]
jrst pdlnkj
which is wrong and weird. I've noticed that complr is doing a lot of
unnecessary stack saves and pdlnmk's lately. Complr used to produce
really beautiful code. What's happened?
∂02-May-82 2117 REM via SU-TIP (SSTATUS GCMAX 'ARRAY <n>) still not working
To: BUG-PLISP
Do you have any plans to ever look at this bug?
(It's been over 2 years!)
∂25-Dec-79 1805 RPG -- [PLISP: (SSTATUS GCMAX 'ARRAY <n>) ignored]
I'm going to try to investigate this a little over the next few days,
if possible.
-rpg-
;;Here's a transcript of the bug still present in 1982:
.DA
Sunday 2-May-82 20:48 61F 16C
.R PLISP
LISP 2133
Alloc? N
*
↑D ;Turns on printout for GC and allocation statistics
(GC)
;GC DUE TO USER
; 403[25%] LIST, 770[98%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 465[30%] SYMBOL, 756[96%] ARRAY WORDS FREE
NIL
(STATUS GCMAX 'ARRAY) (STATUS SPCSIZE 'ARRAY)
1000
1000
(SSTATUS GCMAX 'ARRAY 10000)
T
;If this were working correctly, it wouldn't do a GC until ARRAY space
; had reached 10000. But as you see it's keeping ARRAY space at 1000-2000
; and doing GC over and over against my desires:
(PROG () L (SETQ A (ARRAY NIL NIL 5)) (GO L))
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 3000 WORDS
;GC DUE TO ARRAY SPACE
; 371[16%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 2[0%] ARRAY WORDS FREE
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 4000 WORDS
;ADDING A NEW ARRAY SEGMENT -- ARRAY SPACE NOW 2000 WORDS
;GC DUE TO ARRAY SPACE
; 1343[36%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;GC DUE TO ARRAY SPACE
; 1343[36%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;GC DUE TO ARRAY SPACE
; 1343[36%] LIST, 763[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 461[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
↑C
.REE
?GQUIT*
(STATUS SPCSIZE 'ARRAY)
2000
(STATUS GCMAX 'ARRAY)
10000
;As you see, ARRAY size is still 2000 even though it's been doing GCs which
; weren't supposed to be done until it reached 10000.
;Now for comparison, LIST space does work as it should, here's a transcript:
(STATUS GCMAX 'LIST) (STATUS SPCSIZE 'LIST)
40000
4000
;Notice it's adding new segments without doing any GC, until 40000 is reached:
(PROG () L (SETQ S (CONS NIL NIL)) (GO L))
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 5000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 6000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 7000 WORDS
;... Transcript edited for brevity ...
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 35000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 36000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 37000 WORDS
;ADDING A NEW LIST SEGMENT -- LIST SPACE NOW 40000 WORDS
;GC DUE TO LIST SPACE
; 35342[92%] LIST, 762[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 460[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;GC DUE TO LIST SPACE
; 35342[92%] LIST, 762[97%] FIXNUM, 1000[100%] FLONUM,
; 773[99%] BIGNUM, 460[29%] SYMBOL, 754[48%] ARRAY WORDS FREE
;As you see above, it waited until size reached 40000 before starting
; to do GCs.
↑C
.DA
Sunday 2-May-82 20:53 61F 16C
∂03-May-82 2054 Kent M. Pitman <KMP at MIT-MC>
Date: 3 May 1982 23:53-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC
(setq a (open 'tty: '(in fixnum tty single)))
(in a)↑C
;(IN #FILE-IN-|TTY:* *|-70776) EOF - IN
IN does not see control-C in a file as an EOF, I don't know why it should
on the TTY. In particular, if the person has the tty open, he ought to know
he does anyway. If he wants to interpret ↑C as an eof, it seems easy for him
to do so. I imagine it is probably irritating to anyone that tries this that
↑C is trapped in this way ...
I don't need this to work for code, so it's not worth fixing for now unless
it is bothering someone else. I just thought I'd note the problem.
-kmp
∂05-May-82 1853 Leonard N Zubkoff <Zubkoff at Cmu-20c> Changes to Maclisp
Date: Wednesday, 5 May 1982 21:48-EDT
From: Leonard N Zubkoff <Zubkoff at Cmu-20c>
To: Steele at CMU-20C, Fahlman at CMU-20C, Jonl at Parc-Maxc,
Bug-Lisp at mc
Subject: Changes to Maclisp
We've recently discovered a peculiar interaction between MacLisp and the
migration system program (reaper). It seems that some .fasl files that were
being accessed by MacLisp frequently were not having their last-read dates
updated properly, causing them to be migrated and thus making MacLisp unusable
until they were restored.
Our system programmer, Aaron Wohl, postulates that this is caused by MacLisp's
first opening a file with the do-not-update-read-date bit set (Of%Pdt) and then
actually opening the file for reading. Apparently, the monitor is then failing
to update the read date on the second file opening as well. Searching through
the Lisp sources, it appears that the only place such an Openf% is ever used is
in the function FASLP; also, it seems highly likely that most uses of FASLP
would be immediately followed by actually reading the file.
In order to alleviate this problem, I've built and installed Lisp version 2130
on CMUC using a modified QIO.mid with the following changes:
(1) Of%Pdt is no longer set on the Openf% in FASLP.
(2) All GtJfn% calls have had the Gj%Acc removed, so that the files are visible
(this change in response to discussions with Jonl indicating that this would be
a good idea).
If whoever is responsible for maintaining the master Lisp sources would make
these changes there as well, it would be appreciated. Alternatively, just
ftp the file Ps:<MacLisp>Qio.mid.751 from CMUC.
Leonard Zubkoff
∂05-May-82 2007 FEINBERG at CMU-20C Changes to Maclisp
Date: 5 May 1982 22:29-EDT (Wednesday)
From: FEINBERG at CMU-20C
To: Leonard N Zubkoff <Zubkoff at CMU-20C>
CC: Bug-Lisp at MC, Fahlman at CMU-20C
Subject: Changes to Maclisp
--Text follows this line--
Howdy!
I believe the Jonl has already updated maclisp wrt Gj%Acc.
As for Of%Pdt, I suspect that the monitor bug should be
fixed, not Maclisp. Certainly checking to see if a file is a FASL
file should not constitute reading it. I suggest that we just run
with your modified version of Maclisp on CMUC until Aaron Wohl gets
around to fixing the bug. Also, perhaps there is a way to prevent the
reaper from reaping the <MACLISP> directory, which I think is a bad
idea in the first place. It is hard enough to keep Maclisp running
without files magically disappearing onto tape. Unless a significant
number of other sites are encountering this problem, we should stick
with a local fix.
--Chiron
Subject:
∂06-May-82 1046 JONL at PARC-MAXC Of%Pdt
Date: 6 MAY 1982 1041-PDT
From: JONL at PARC-MAXC
Subject: Of%Pdt
To: zubkoff at CMUC, feinberg at CMUC
cc: fahlman at CMUC, bug-lisp at MIT-MC
Feinberg's note was quite right -- I've already edited the MC
sources for the Gj%Acc change. I also agree with him that no change
should be made in the Lisp semantics for what appears to be
a CMU-specific bug (failure to update read date doesn't occur
at XX). Perhaps most TOPS-20 systems do reap the <maclisp> directory,
but the corresponding directory on the ITS machines is maintained
"by hand" for just the reasons noted -- the
difficulty of maintiaining a coherent systems when
critical, but seldom referenced, parts disappear randomly.
∂10-May-82 1215 OTADUY PEDRO J. <PJO at MIT-MC>
Date: 10 May 1982 15:11-EDT
From: OTADUY PEDRO J. <PJO at MIT-MC>
To: BUG-LISP at MIT-MC
This is Pedro at ORNL.
I am trying to get Maclisp version 2022 up in our KA10-TOPS10.
I have found bugs in array related functions.
FILLARRAY,FILEPOS,IN and LOADARRAYS have fatal BUGs in this version.
I have observed that they are not present in the version presently
running at your MC site. Can anyperson give me the patchup recepy?
FILEPOS symptoms:
Let 0=<n<(FILEPOS fi) ...then... (FILEPOS fi n) gives UUO error @440410
FILLARRAY symptoms:
Let (FILEPOS fi)=0 be case #1 ,
(FILEPOS fi)>0 be case #2 ,
(FILEPOS fidump)=3 be case #3 where fi is a FIXNUM file OPen for INput
created by (FILLARRAY fi 'ARRAYX) , and fidump is same but created by
a DUMPARRAYS command.
THEN...
(FILLARRAY 'ARRAYN fi) Halts at 444066 for both cases #1 and #2...but
on reentering 'ARRAYN shows to be unchanged in case #1 ,while
'ARRAYN shows the correct info in case #2.
ON the other hand (?) case #3 works satisfactorily.
LOADARRAYS was not working at all.Upon some study i found IN to be the culprit.
Replacing the JUMPN 10,452756 @453015 (inside IN) with a JUMPG ... instruction did fix LOADARRAYS. Now i don't know if this is Kosher but it works.
Gratious reader of this missive...if you can help with these bugs and do so I will be most grateful. Also, are there any other bugs I should be aware
of?
THanks. sincerely..pedro.
∂14-May-82 1432 David M. Krowitz <DAVID at MIT-AI>
Date: 14 May 1982 16:51-EDT
From: David M. Krowitz <DAVID at MIT-AI>
To: BUG-LISP at MIT-AI
When I try to compile lisp 2129 using the TOPS10 switch, I get the
following error messages:
sharp1+1 3060 2. 37-022 ###### HOW TO SHARE WITH "PURQIO" FILE?
gethgh 3107 0. 38-079 VECALL Undefined
I am using midas 428 running under tops10 version 6.03A on a regular
KA10 (ie. no paging hardware has been added). In addition to these error
messages, the lisp version number is typed out as 687194. I am able
to load the relocatable binary file which is provided with the lisp
distribution tape, but it seems to run out of memory space very quickly.
typing something like (ARRAY FOO T 5000.) usually result in
a "can't get core" message. Trying to load COMPLR.FAS runs into the same
problem.
--david krowitz
∂14-May-82 1609 JONL at PARC-MAXC Assembling MacLISP under TOPS-10
Date: 14 MAY 1982 1607-PDT
From: JONL at PARC-MAXC
Subject: Assembling MacLISP under TOPS-10
To: david at MIT-AI
cc: BUG-LISP at MIT-MC
Several mesages will be printed out that do not reflect true
"errors", but were merely inserted in the source code so that
the lisp maintainers would be reminded of some lacunae
in the non-ITS versions. The comment about "###### HOW TO SHAR WITH PURQIO FILES"
is no problem.
On the other hand, the VECALL undefined is a true error, and is
probably symptomatic of some failure to conditionalize code for
the SAIL-specific assembly (SAIL is a variant of TOPS-10).
It's generally true that non-virtual-memory TOPS-10 sites have
troubles running anyything interesting in MacLISP; a total
core allotment of about 100K would be reasonable for the Compiler,
and as I recall, many sites restrict the random user to about
40K or so. See if you can get a larger allotment "late at nite".